System of Systems Capability to Requirements

Given an existing set of interconnected, independent systems, often referred to as a system of systems (SoS), one of the key activities according to the United States Department of Defense Systems Engineering Guide for Systems of Systems is “translating SoS capability objectives into high-level SoS requirements”. Capability engineering starts with understanding the desired capability and identifying various options for achieving that capability, technically assessing the various alternatives, then further evaluating the most viable alternatives in terms of capability performance, cost, and schedule. This paper provides additional guidance for translating capability objectives into requirements; defines SoS engineering methods, processes, and tools that might support this activity; and illustrates how the methods, processes, and tools would be used and integrated to support SoS engineering using an example SoS. Introduction Given an existing set of interconnected, independent systems, often referred to as a system of systems (SoS), one of the key activities according to the DoD Systems Engineering Guide for Systems of Systems [1] is Translating SoS Capability Objectives into High-Level SoS Requirements. According to the DoD SoS guidebook: When a formal SoS is first identified, the systems engineering team is called upon to understand and articulate the technical-level expectations for the SoS. SoS objectives are typically couched in terms of needed capabilities, and the systems engineer is responsible for working with the SoS manager and users to translate these into high-level requirements that can provide the foundation for the technical planning to evolve the capability over time. To accomplish this, the SoS SE team needs to understand the nature and the dynamics of the SoS both to appreciate the context for SoS expectations and to anticipate areas of the SoS that are most likely to vary in implementation and change over time. The SoS systems engineer has a continuous active role in this ongoing process of translating capability needs into technical requirements and identifying new needs as the situation changes and the SoS evolves. The DoD SoS guidebook further discusses this activity in more detail: At the outset of an SoS effort, one of the first tasks facing the SoS manager and systems engineer is to develop a basic understanding of the expectations for the SoS and the core requirements for meeting these expectations. In an SoS, objectives are often stated in terms of broad capabilities. The SoS systems engineer and manager review objectives and expectations on a regular basis as the SoS evolves and changes occur in user needs, the technical and threat environments, and other areas. The SoS SE team also provides feedback to the manager and stakeholders on the viability of meeting SoS objectives, particularly given the results of other SoS SE core elements. This SoS SE core element involves codifying the SoS capability objective, which may be stated at a high level, leaving the task of clarifying and operationalizing the objectives and expectations to the SoS manager, systems engineer, and stakeholders. The following examples illustrate the type of capability objectives an SoS might have:  Provide satellite communications (MILSATCOM)  Provide global missile defense (BMD)  Provide a single view of the battle space for all customers (SIAP) Once the SoS establishes the capability objective (often based upon desired operational tasks and missions), the SoS SE team defines the functions required to provide the capability and the variability in the user environment which will impact the different ways these functions will be executed. The articulation of objectives may be somewhat general at the outset, but as the SoS and SE processes mature, the objectives become more focused and they may change. ‘Reference missions’ or ‘use cases’ can be developed to evaluate the operational utility of the SoS and derive requirements that directly address usability of the SoS in the operational environment. Working with the SoS manager, users, and stakeholders, the systems engineer plays an important role in articulating capability objectives. This activity provides the systems engineer with a broader understanding of priorities and relationships, and that understanding will be useful in the further development and management of requirements. The product of this element is a set of requirements ready for incorporation to a future functional baseline for the SoS. Within this core element the systems engineer develops a broad understanding of the context and drivers for the SoS. Beyond the specific functionality needs, it is very important for the systems engineer to have a good understanding of the motivation for the SoS, particularly the need to be more responsive to the increasing change tempo of the battle space, be it cyberspace, non-nation state terrorism, or health care management for veterans. Because SoS tend to evolve over time, the systems engineer needs to understand and continue to track the dynamics of change as they influence the SoS objectives and expectations. This provides the drivers for the SoS SE element ‘monitoring and assessing change’; in effect, it provides the context to help the systems engineer anticipate the type of changes and variability the SoS will need to address over time. As illustrated in figure 1, capability engineering starts with understanding the desired capability and identifying various options for achieving that capability. Initial capability engineering is typically done by assessing available resources and assets to identify existing functions from which the new capability can be composed (AF SAB report), followed by a gap analysis for each alternative identified. Finally, each alternative is further evaluated in terms of capability performance, cost, and schedule resulting in information that can be used to support the trade decision. Figure 1. Overview of Translating Capabilities into Requirements. The goal of this research effort was to:  Provide additional guidance for translating capability objectives into requirements  Define SoS engineering (SoSE) methods, processes, and tools (MPTs) that might support this activity  Illustrate how the SoSE MPTs would be used and integrated to support SoS engineering using Regional Area Crisis Response SoS (RACRS) example While many of the techniques and methods described here are not new, they are used in ways tailored to support SoS and SoSE analyses and integrated together through a process to support capability-torequirements engineering in a more rigorous, repeatable manner, resulting in meaningful information about alternatives that can be used to support a final decision on how the capability will be implemented. The MPTs described here are illustrated using a notional example, the Regional Area Crisis Response System (RACRS), described in [2]. This example has been developed to support research using actual systems in the public domain that are employed to respond to regional crisis situations [2]. RACRS Background The motivation for RACRS, as described in [2], is based upon recent catastrophes that have happened in recent years within the United States: hurricane Katrina, devastating fires in California, powerful earthquakes in the western United States, and tornadoes in the Midwest United States. Early responders to these incidents found that communications between the different local agencies was difficult at best and often not integrated. When state and federal agencies became involved, the communications problems escalated. As a result, efforts have been initiated to establish a way to better integrate the needed agencies in response to a given incident. The goal is that the agencies will generally operate on their own outside of the SoS, then quickly be able to dynamically reconfigure and join the regional SoS as needed, typically in response to an incident. Overview of Capability-to-Requirements MPTs The Capability-to-Requirements process is illustrated in figure 2. This figure identifies techniques and methods that can be used to support the engineering activities associated with each step. Figure 2. Capabilities-to-Requirements Tools to Support Engineering Activities. The following sections describe each of the tools and how they are used in the capability-torequirements engineering process. UML Object Models Several UML object models are used to understand the SoS and its constituent systems as well as to identify/understand single system functions that can be used to develop new capabilities and to assess and define the various options for implementing a new capability. These models begin with “black box” models to understand the SoS and its constituents at a high level and evolve to “white box” models that capture the internal information about the constituent systems needed to understand options for various SoS capabilities. These SoS models, described in [2], include: Black box models a. Context diagrams: Identifies systems of interest in the SoS from selected system viewpoints as well as who and what will interact and what types of information will be passed. b. Use case diagrams: Describe how the SoS capabilities of interest work. These diagrams can be used to model the “as is” SoS capabilities as well as alternative “to be” options for the new capability. c. Sequence diagrams: Illustrates the sequence of requests and responses that flow within the SoS environment for capabilities of interest. White box models: a. Constituent system entities: Describes the key functions and single system capabilities that can be performed by the single system. b. Interface entities: Describes the each interface in the SoS and the information that goes over that interface. c. Input/Output (I/O) entities: Describes the details of each data element type that goes over the various interfaces. Responsibility/Dependability Modeling Responsibility modeling [3] captures information about that can be used to identify socio-technical threats to the dependability of constituents in a coalition of systems or SoS. For each responsibility/ capability of interest and resource/constituent system within the SoS, available resource agents that can support the capability are identified. In the second part of this modeling, the dependability of the each agent is assessed through a risk analysis process. Interoperability Matrices The level of interoperability between the various constituents in an SoS are captured in an N diagram where all of the constituent systems are listed both across the top and down the left side of the matrix. Each of the other boxes in the matrix indicates the level of interoperability between each of the two systems associated with that row/column. The method used to specify the level of interoperability in the N diagram is the Levels of Information System Interoperability (LISI) [4]. Data fusion analyses For capabilities requiring data fusion, [5] provides guidance for trades must be performed with respect to level of fusion, functional aggregation, producer-consumer reconciliation, incongruent or inconsistent metadata management, concept of operations with respect to the fusion(s), fusion lifecycle, network topology, and information assurance. COSYSMO for SoS Once viable alternatives have been identified and evaluated with respect to feasibility and risks, the final step is to evaluate the costs of implementing the various alternatives. The Constructive Systems Engineering Cost Model (COSYSMO) for SoS [6], illustrated in figure 3, can be used to evaluate the relative systems engineering costs of each alternative. Figure 3. COSYSMO for SoS Overview To develop a complete cost estimate, additional cost models in the USC CSSE Constructive Cost Model (COCOMO) family [7] can be used to estimate the costs of Commercial-Off-the-Shelf (COTS) integration and software development. The final cost estimate must also include the costs of hardware procurement/manufacturing that might be required for the alternative of interest. RACRS Analysis using Capability-to-Requirements MPTs For the purposes of this example, the current desire is to enhance the RACRS to provide the following improved/new capabilities: 1. Improve number of fire-fighting resources available to fight major fires in the region. (Currently RACRS is limited to local civil responders augmented with available civil responders from other areas as well as low-risk inmates from local prisons/jails.) 2. Further reduce the time and number of official crisis management personnel resources required to evacuate a specified area/region. This capability includes the ability to quickly determine areas that require evacuation and appropriate evacuation routes as well as the ability to evacuate large numbers of people that do not have transportation (e.g., assisted living residences, hospitals, jails). 3. Protect evacuated areas from looters. At the same time, the RACRS stakeholders want to: 1. Minimize local government expense (city, county) 2. Minimize risk to human life (crisis responders and local population) 3. Minimize workload on skilled personnel responsible for responding to crisis. The following identifies potential resources that might be used to provide improved/new capabilities: 1. Local: fire fighters, police, and sheriff personnel 2. Volunteer civilians 3. Military personnel at local bases 4. Low-risk inmates incarcerated in local jails 5. Unmanned aerial vehicles (which require people to remotely operate) 6. Unmanned ground vehicles (which require people to remotely operate) 7. TV/radio station announcers 8. Satellite and local road camera images showing crisis area (e.g., fire) and traffic status 9. Buses for transporting people 10. New system: Reverse-911 system that calls homes/residents of given area and tells them when, how, and where to evacuate to via pre-recorded messages. 11. Homeowner alarm/security systems to notify people of need to evacuate, notify security patrols of break-ins, potential looters. The following illustrates how the above MPTs might be employed to develop a set of requirements to fulfill the desired capability improvements. Identify resources The constituents of interest for this version of the SoS are those described in [2]: • Satellite imaging system: Provides images of interest to requestor • Fire department: Manages the fire response units • Police department/sheriff’s department: Provides safety and crime-fighting support that includes evacuation support and protection from looters • Handheld devices: Provides connectivity to crisis responders on the ground via voice and video • Reverse-911: Automatically sends voice messages to people that reside or work in areas that need to be immediately evacuated. • Regional area planning and land use data: Includes building plans, building locations, and maps for utilities (electricity, water, sewer) for regional areas of interest • Unmanned aerial vehicles (UAVs): Used for surveillance, lightweight fire retardant drops, and can also be armed to start needed backfires or fire upon looters/rioters • Unmanned ground vehicle (UGV): Provides on the ground video feeds in situations where it is too dangerous for personnel clearing of brush/small trees to create fire breaks • Aerial water tanker: Canadian asset shared among multiple U.S. regional areas to drop water on hot spots • News helicopter: Used to capture video feeds for news programs—includes news events as well as traffic flows and may also be used to monitor for signs of looting • Command and control center (CCC): Central site to monitor and help coordinate activities support decision makers. The constituent systems that interoperate with the CCC for the RACRS fire-fighting scenario are illustrated in the CCC context diagram shown in figure 4. This is the “black box” view of the CCC and is used to understand at the top level the constituent systems related to fire-fighting from the CCC point of view. Figure 4. CCC context diagram [2]. Identification of Capability Alternatives The initial analysis evaluates the feasibility of utilizing military resources in the region to support firefighting and then focuses on improving the manpower requirements needed to support the evacuation process. Potential alternatives to consider for the improved evacuation capability are: 1. Use current local patrols (police/sheriffs) (e.g., personnel employing loudspeakers, roving patrols, roadblocks) 2. Use civilian (volunteer) patrols (e.g., personnel employing loudspeakers, roving patrols, roadblocks) 3. Use unmanned vehicles (combination of ground and aerial that can warn of potential harm/record suspicious activities. 4. Rely on homeowner alarms to notify patrols 5. New reverse-911 system that can be used to automatically notify residents in a given area to evacuate. Analysis of Alternatives The various MPTs are illustrated below and show how they can be used to support the analysis of capability alternatives. Responsibility/Dependability Analysis: To start the analysis of alternatives, a responsibility matrix is developed that lists the various capabilities in the left-hand column and the potential resources across the top, as illustrated in table 1. Table 1. RACRS Evaluate Area Responsibility Matrix. Responsibility Resources Fire trucks Sheriff cars Water tankers UAV Reverse 911 system Ambulances Buses Manual Fight fire Local Regional Military Local Canadian company Military Local Regional Military Volunteer